Techniques For Delivering Personalized Content With A Real-Time Routing Network

ABSTRACT

Techniques for dynamically updating a live object with personalized content for clients are provided. The techniques include receiving a first message from a source including a first identifier and a second identifier. The first identifier may be unique to a client. The second identifier may be generic across many clients. The first message includes information for updating a property of a live object associated with the second identifier. A client specific to the first identifier may be identified. A second message may then be routed through a network to the client. The second message may include the first identifier and the second identifier and also may contain information for updating a property of the live object associated with the second identifier. The client may receive the second message and may be capable of causing an update of the property of the live object associated with the second identifier.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority from co-pending U.S. Provisional PatentApplication No. 60/602,539, filed Aug. 17, 2004, entitled “TECHNIQUESFOR DELIVERING PERSONALIZED CONTENT WITH A REAL-TIME ROUTING NETWORK,MODULAR EVENT-DRIVEN ARCHITECTURE, MODULAR EVENT-DRIVEN PROCESSING ANDVIEWER FAILOVER TESTING A SYSTEM MEMORY WHILE AN OPERATING SYSTEM ISACTIVE”; and is a continuation in part of U.S. patent application Ser.No. 10/017,182, entitled “ASYNCHRONOUS MESSAGING USING A DYNAMIC ROUTINGNETWORK”, filed Dec. 14, 2001, which claims priority from U.S.Provisional Application No. 60/256,613, filed Dec. 18, 2000, U.S.Provisional Application No. 60/276,847, filed Mar. 16, 2001, U.S.Provisional Application No. 60/278,303, filed Mar. 21, 2001, U.S.Provisional Application No. 60/279,608, filed Mar. 28, 2001, U.S.Provisional Application No. 60/280,627, filed Mar. 29, 2001. All of theabove applications are hereby incorporated by reference, as if set forthin fill in this document, for all purposes.

BACKGROUND

Embodiments of the disclosure generally relate to transferringinformation through networks and in particular to transferringpersonalized information for remotely updating content at client devicesthrough the networks.

Users may download many different kinds of content from the World WideWeb. For example, users may download content using web pages. In somecases, users may subscribe to services that send content that the users'desire to the web pages. Content providers may need to keep track ofwhich users registered for which content. In addition to keeping trackof which users registered for which content, the service providers mayalso need to know how to send the content that each user registered for.This may require a large amount of resources to keep track of the userswho have registered, the content each user desires, and how to route thecontent to the users.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram illustrating an environmentcontaining a dynamic content routing network;

FIG. 2 is an interaction diagram illustrating interactions among aserver, information provider, dynamic content provider, client, androuting network to update a property of a live object on a web page;

FIG. 3 is a high-level diagram graphically indicating the many-to-manymapping performed by the routing network;

FIG. 4 illustrates two different web pages containing sports scores;

FIG. 5 is a block diagram illustrating an input source and the toolsavailable to it for generating the update messages;

FIG. 6 is a flow chart illustrating the steps performed by an embodimentof an activation module;

FIG. 7 is a block diagram illustrating a lower-level view of the routingnetwork according to an embodiment;

FIG. 8 is a flow chart illustrating steps performed by a node in acluster to perform object-based routing of a message received from aninput source via the gateway;

FIG. 9 depicts an example of a web page according to one embodiment;

FIG. 10 depicts a system for delivering personalized messages usingrouting network 110 according to one embodiment;

FIG. 11 depicts a simplified flowchart for generating a batch messageaccording to one embodiment;

FIG. 12 depicts a simplified flowchart of a method for routing a batchmessage to a client according to one embodiment; and

FIG. 13 depicts a simplified flowchart for a method for processing abatch message at a client according to one embodiment.

A further understanding of the nature and the advantages of theembodiments disclosed herein may be realized by reference of theremaining portions of the specification and the attached drawings.

DETAILED DESCRIPTION

In one embodiment, personalized content may be provided to remoteclients using a dynamic content routing network. The dynamic contentrouting network is described first and then delivering personalizedcontent to clients is described.

Dynamic Content Routing Network

FIG. 1 is a high-level block diagram illustrating an environment 100containing a dynamic content routing network 110 (hereafter referred toas the “routing network”). The environment 100 also contains a server112 in communication with a client 114, an information provider 108, anda dynamic content provider 116. Although a typical environment 100 willhave hundreds of servers 112 and information providers 108, thousands(or even millions) of clients 114, and multiple dynamic contentproviders 116, FIG. 1 illustrates only one of each of these entities inorder to enhance the clarity of this description.

The server 112, client 114, information provider 108, dynamic contentprovider 116, and routing network 110 are preferably in communicationvia conventional communications links 117 such as those comprising theInternet. The communications links 117 include known wiredcommunications media, such as dedicated or shared data, cable televisionor telephone lines, and/or known wireless communications media, such ascommunications over the cellular telephone network using protocols suchas the global system for mobile communications (GSM), code divisionmultiple access (CDMA), time division multiple access (TDMA), etc.

In one embodiment, the entities may each be in communication with one ormore Internet Service Providers (ISPs) (not shown) that provide eachentity with access to other computers on the Internet. In addition, theserver 112, client 114, information provider 108, dynamic contentprovider 116, and routing network 110 are preferably each identified byat least one Internet Protocol (IP) address such as “66.35.209.224.” TheIP address may also have one or more domain names associated with it,such as “bangnetworks.com.” Alternative embodiments of the presentinvention may use alternative addressing schemes and/or namingconventions instead of, or in addition to, those described herein. Forexample, embodiments wherein one or more of the clients are cellulartelephones or other portable devices may rely on different addressingschemes.

Preferably, the information provider 108 provides web pages or otherrepresentations of data to the server 112. The web pages contain one ormore “live objects,” which are designated to be real-time dynamicallyupdateable objects. Each live object is identified by an objectidentifier, or object ID. Preferably, the server 112 provides the pages118 to multiple clients 114. The clients 114 contact the routing network110 and register for update messages for the object IDs on the web page.The routing network 110, in turn, preferably maintains a registryindicating which clients have registered for which object IDs.

The information provider 108 and/or dynamic content provider 116 sendupdate messages to the routing network 110. These messages can be sentany time the information provider 108 or dynamic content provider 116wants to update a property of a live object. Each update messagepreferably identifies a live object and contains data for updating aproperty of the identified live object. The routing network 110 accessesthe registry and determines which clients have registered for theidentified object. Then, the routing network 110 routes the updatemessage to the appropriate clients. Upon receipt of an update message,the clients 114 update the specified property of the live object.

The routing network 110 provides an efficient one-to-many mapping ofobjects to clients (and by inference of information, a many-to-manymapping of information providers 108/dynamic content providers 116 toclients) through object-based routing. Messages provided by theinformation provider 108 and/or dynamic content provider 116 to therouting network 110 are not routed to the clients 114 based entirely ona specified destination; more specifically, they are not routed based onthe IP address of the client, as in conventional IP routing schemes.Instead, the messages are routed based on the live objects referenced bythe message.

The mapping and object-based routing provided by the routing network 110allow the information provider 108 and dynamic content provider 116 toupdate properties of live objects at a dynamically changingcross-section of clients in real-time, without requiring the informationprovider or dynamic content provider to track the clients or web pagesbeing viewed by the clients. The clients 114, in turn, do not need tohave any a priori knowledge of object IDs—they “discover” which IDs theyshould register when they receives the pages 118 from the server 112.

Object-based routing also allows information providers 108 todynamically update content on web pages without requiring the clients114 to re-request the content, and without requiring the informationproviders 108 or servers 112 to maintain connections with the clients.In this manner, significantly more clients can receive updated contentfrom a given information provider 108 than would be possible utilizingconventional client-side request-driven transmission controlprotocol/Internet Protocol (TCP/IP) connections between the clients andthe server 112.

Turning now to the individual entities illustrated in FIG. 1, the server112 is preferably a conventional computer system configured to act as aweb server and serves pages 118 and other data representations toclients 114. The pages 118 provided by the server 112 are associatedwith one or more information providers 108.

An information provider 108 is an entity providing one or more pages118, information contained in web pages, and/or other representations ofdata served by the server 112. The information provider 108 preferablyhas a conventional computer system coupled to the Internet. In oneembodiment, the server 112 is directly controlled by the informationprovider 108 (e.g., the server is physically located at the informationprovider and/or is dedicated to serving only the information provider'sweb pages). In this embodiment, the server 112 and information provider108 can be treated as the same entity. In an alternative embodiment, theserver 112 serves web pages from multiple information providers.

As is known in the art, the pages 118 and other content on the server112 are specified by uniform resource locators (URLs) having the form“service://server/path/web page.” Typically, pages 118 are obtained viathe hypertext transport protocol (HTTP) and thus an exemplary URL forretrieving the web page “b1.html” from the web server having the domainname “www.bangnetworks.com” is“http://www.bangnetworks.com/news/b1.html.”

As used herein, a “web page” is a block of data available from theserver 112. In the simplest case, a web page is a file written in thehypertext markup language (HTML). The web page may also contain or referto one or more other blocks of data, such as other files, text, images,applets, video, and/or audio. In addition, the Web page may containinstructions for presenting the web page and its content, such as HTMLtags and style sheets. The instructions may also be in the ExtensibleMarkup Language (XML), which is related to HTML and adds semanticcontent to web pages or the Dynamic HTML (DHTML), which adds somedynamic content to web pages. Additionally, the instructions may takethe form of one or more programs such as JAVA® applets and JAVASCRIPT®and/or DHTML scripts.

As used herein, the phrase “web page” also refers to otherrepresentations of data served by the server 112 regardless of whetherthese data representations include characteristics of conventional webpages. These data representations include, for example, applicationprograms and data intended for the web browser 120 or other applicationprograms residing at the clients 114 or elsewhere, such as spreadsheetor textual (e.g., word processing) data, etc.

In a preferred embodiment, objects at the client, such as web pages andelements of web pages, can be designated as “live” by the informationprovider 108. Properties of a live object can be dynamically updated inreal-time at the client 114 by the information provider 108 or anotherentity acting on behalf of the information provider. As used herein, an“object” is any datum or data at the client 114 that can be individuallyidentified or accessed. Examples of objects include elements of webpages such as text characters and strings, images, frames, tables,audio, video, applets, scripts, HTML, XML, and other code forming theweb page, variables and other information used by applets, scriptsand/or code, URLs embedded in the web page, etc. Application andoperating system constructs are also objects. For example, cells ofspreadsheets, text in word processor documents, and title bars andmessages displayed by the operating system or applications are objects.Preferably, multiple objects can be grouped together into a single,logical object. Thus, an object can be defined at any desired or usefullevel of granularity.

Since content on a web page is conceptualized and organized by “object,”the present invention essentially abstracts web pages and web pagecontent, and other modules and/or functionality at the client 114, awayfrom the HTML code or other conventional representation. Thisabstraction allows the information provider 108 to update a property ofan object without concern for the location, display format, or otherspecifics of how the data is being represented at the client 114.

Live objects have associated “properties” which include any modifiabledata related to the object or referenced with respect to the object. Theinformation provider 108 typically, but not necessarily, providesinitial settings for the properties of live objects provided to theclient 114. The properties may or may not affect the visualrepresentation of the object in the web page or other datarepresentation. A property may affect an internal aspect of the objectand, thus, a change to the property may not have any direct effect on aweb page containing the object. For example, the property may affectwhether particular aspects of the object are modifiable, how the objectresponds to user input or other stimuli, etc. Additionally, a propertymay also have a direct effect on how the object is displayed at theclient 114. For example, the property may affect the content, color,typeface, size, formatting, or other attribute of text, images, or otherdata displayed by the object. Other properties may occupy parts of thespectrum between having no effect on the visible representation of theobject and having a direct effect on the visible representation of theobject. For example, a web page showing scores of football games mayinclude a list of games and the current scores of the games as of thetime the server 112 serves the web page. The list of games, subset ofgames to be displayed, and the scores of the games can be designated aslive objects (or properties of a single live object) and updated asnecessary or desired.

A property can also preferably include instantiating an instance of theobject or invoking functionality of the object. For example, a propertyof a browser window object may include functionality for instantiatinganother browser window. This function can be invoked as a logical changeto a property of the object. The second browser window can be referencedthrough the original browser window (i.e., object) or designated as anew live object.

An information provider 108 or other entity preferably updates a liveobject at a client 114 via an update message. In general, an updatemessage identifies the live object and, if necessary, the property ofthe live object, and contains data for updating the property. In oneembodiment, the data may be the actual value for the property orexecutable code for causing the object's property to be updated. Forexample, the data may, be a simple numerical or textual value, e.g.,“4,” to which the property should be set, and/or the data may beJAVASCRIPT® code or a call to a JAVASCRIPT® function at the client thateffects the desired change to the property of the object.

The update message preferably implicitly or explicitly identifies ahandler at the client 114 for use in updating the live object'sproperty. In one embodiment, the client 114 utilizes a default handlerwhen the message implicitly specifies the handler (e.g. when the messagedoes not identify a specific handler). In one embodiment, if the updatemessage specifies the actual value for the property, a default handlergenerates JAVASCRIPT® code for changing the property to the specifiedvalue. If the data in the update message are JAVASCRIPT® code, thedefault handler does not perform any processing of the code. In eithercase, the default handlers preferably use LiveConnect to execute theJAVASCRIPT® code in a Java Virtual Machine (JVM) 122 at the client 114and thereby update the property of the live object.

For certain objects and/or data types, the default handlers are notappropriate. In these cases, the message preferably explicitlyidentifies a handler for performing the update. For example, the messagemay explicitly specify a function to call on the data or the message mayexplicitly identify the environment in which the data should beexecuted. For example, the data in the update message may include codefor execution by a software “plug-in” such as MACROMEDIA FLASH® and themessage may explicitly identify FLASH as the handler.

The information provider 108 preferably designates an object as “live”by including a unique identifier for the object, the object ID, in theweb page or other data representation provided to the client 114. In oneembodiment, the information provider 108 encodes the object ID in anobject's corresponding HTML “ID” attribute using the following HTMLexpression:

ID=“elementIdentifier,”

where “elementIdentifier” is the object ID and is preferably a string.The string can encode any information desired by the informationprovider 108 or other entity establishing the object ID and in oneembodiment is a simple textual and/or numeric identifier. In oneembodiment, the information provider 108 begins the object ID with apredefined token, such as “Bang$,” in order to distinguish live objectsfrom other objects that happen to have defined ID attributes. Forexample, an object can have the object ID “Bang$elementIdentifier.”

In the preferred embodiment, each information provider 108 optionallyencodes a unique information provider ID in its object ID in order toprevent naming collisions between the object IDs of differentinformation providers. In one embodiment, the information provider ID isa textual and/or numeric identifier. The information provider 108 mayspecify the information provider ID and the object ID as part of ahierarchical namespace. For example, in one embodiment objects are namedas follows: “$namespace1$[namespace2$ . . . $namespaceN$]objectId,”where “$namespace1” is the information provider ID and the “$” operatesas the name separator and defines additional optional levels of anamespace hierarchy. One embodiment of the system 100 supports typicaldirectory services functionality. For example, two dollar signcharacters appearing together, “$$,” refers to the top level of thenamespace hierarchy.

Thus, the object ID for a live object is preferably formed from acombination of the predefined token, the information provider IDnamespace, and a value assigned by the information provider 108. Forexample, the object' for a live object representing the real time priceof a stock having the symbol “BANG” might be:“Bang$$informationProviderID$equities$realtime$bang.” In this example,“Bang$” is the predefined token that signifies a live object,“$informationProviderID” is the ID identifying the information provider,“$equities$realtime$” defines levels of a namespace hierarchy, and“bang” identifies the specific object.

In some embodiments and situations, the object ID utilizes relativenames. For example, an information provider 108 referring to its ownobject IDs is implicitly in its own namespace. Accordingly, theinformation provider 108 does not need to include the informationProvider ID in the object IDs it utilizes internally. In one embodiment,the information provider ID is not explicitly encoded into the objectID. Instead, the information provider ID is encoded elsewhere in the webpage in order to provide scope to the page's object IDs.

In one embodiment, the object ID identifies a point (i.e., a node in atree) in a Document Object Model (DOM) representation of a web page orother document at the client 114. The DOM is a platform- andlanguage-neutral interface that represents a document as a hierarchy ofobjects. The DOM also provides an interface that allows programs andscripts to dynamically access and update properties of the objects.Object properties can be inherited by descendent objects.

In this embodiment, the client 114 preferably executes an update messagein the context of the specified point in the DOM representation. Theupdate may specify a change to a property of the object at theidentified point. The update also may specify a change to a parent ordescendent of the object at the identified point. In each case, theupdate is executed relative to the specified point in the DOMrepresentation. In one embodiment, points in the DOM representationspecify how to update properties of live objects located at thosepoints. Thus, the same update may be interpreted differently dependingupon the identified live object's location in the DOM representation.

For example, assume there is an object in the DOM representationidentified as “window.document.frame[3].ObjectID.” Also assume that theobject has an “innerText” property located at“window.document.frame[3].ObjectID.innerText” that specifies the textdisplayed by the object. An update message can change the text displayedby the object by specifying “ObjectID” and the new value for theinnerText property.

An advantage of utilizing object IDs to specify objects is that theinformation provider 108 or other entity providing the update messagecan access and change properties of objects without knowing the object'sactual location in the DOM representation. Indeed, the object may be indifferent locations in different DOM representations and/or in multiplelocations in the same DOM representation. In any of these cases, theupdate message will change the specified properties of all of theobjects having the given object D.

Depending upon the particular embodiment of the environment 100, theinformation provider 108 and/or the dynamic content provider 116provides update messages to the routing network 110. The dynamic contentprovider 116 is preferably a conventional computer system operated by anentity that provides real-time information, such as stock prices and/orsports scores. In one embodiment, the information provider 108 receivesupdated properties for the live objects from the dynamic contentprovider 116 or another source (or generates the updated propertiesinternally). Then, the information provider 108 sends an update messagespecifying the object ID and the change to the object property to therouting network 110. In this embodiment, the dynamic content provider116 may be absent from the environment 100.

In another embodiment, the dynamic content provider 116 provides theobject IDs for live objects to one or more information providers 108 andthe information providers 108 distribute the live objects to the clients114. Then, the dynamic content provider 116 sends messages specifyingthe changes to the properties of the live objects to the routing network110. For example, the dynamic content provider 116 distributes an objectID associated with the score of a particular baseball game to theinformation providers 108. Then, the dynamic content provider 116 sendsa message specifying the object ID and an update to a property of theobject that controls the displayed score of the particular baseball gameto the routing network 110. These two embodiments are not mutuallyexclusive and, therefore, some updates may be provided to the routingnetwork 110 by the information provider 108 while others are provided bythe dynamic content provider 116.

The client 114 is a device that retrieves pages 118 and/or otherinformation from the server 112. In one embodiment, the client 114 is aconventional personal computer used by a person to access information onthe Internet. In alternative embodiments, the client 114 is a differentconsumer electronic device having Internet connectivity, such as anInternet-enabled television, a cellular telephone, a personal digitalassistant (PDA), a web browsing appliance, etc. The client 114preferably, but not necessarily, has an associated display device.

The client 114 preferably executes a web browser 120, such as MICROSOFTINTERNET EXPLORER®, for retrieving web pages and displaying them on thedisplay device. In embodiments where the client receives datarepresentations from the server 112 other than conventional web pages,the web browser 120 does not necessarily share similarities withconventional web browsers. Preferably, the web browser 120 contains aJVM 122 for executing JAVA® applets and/or scripts. The web browser 120also preferably contains Dynamic HTML capabilities, such as support forJAVASCRIPT® (or another scripting language, such as VBScript) and theDocument Object Model (DOM), and enables communications between JAVA®and the scripting languages. In one embodiment, the web browser 120supports the LiveConnect standard for enabling communication betweenJAVA® applets and scripts written in the supported scripting languages.The web browser 120 can also be extended through software plug-ins suchas MACROMEDIA FLASH®, REAL NETWORKS REALPLAYER®, and/or APPLEQUICKTIME®. In alternative embodiments, the functionality of the JVM 122and/or other aspects of the web browser 120 are provided by one or moreother functional units within the client 114. The term “module” is usedherein to refer to software computer program code and/or any hardware orcircuitry utilized to provide the functionality attributed to themodule. The web browser 120 and JVM 122 are examples of modules in theclient 114.

In some embodiments, the client 114 does not necessarily have a displaydevice, web browser 120 and/or other components associated with atypical consumer device. The client 114, for example, may be a dedicatedpurpose device having certain aspects of web connectivity such as anembedded HTTP client in a web-enabled appliance or in a controller foran automobile, audio-visual equipment, or some other device.

A page 118 provided from the server 112 to the client 114 preferablyincludes instructions for enabling the live objects on the web page. Theinstructions cause the client 114 to automatically and transparently(i.e., without user interaction) contact the routing network 110 anddownload an activation module 124 for activating the live objects. Inone embodiment, the instructions comprise a URL specifying the locationof the activation module 124 at the routing network 110. In analternative embodiment, the client 114 obtains the activation module 124from the server 112 or another source.

The activation module 124 preferably contains JAVA® instructions forexecution by the JVM 122. However, alternative embodiments of the module124 may encode the instructions in the page 118 and/or the activationmodule 124 using different languages and/or techniques. For example, theinstructions and/or activation module 124 can be embedded in the webbrowser 120 or operating system, either as native code or as plug-ins.In these alternative embodiments, the web browser 120 does not have todownload the activation module 124 from an external source.

The activation module 124 preferably registers object IDs from the page118 downloaded by the client 114 with the routing network 110 andupdates the live objects in response to update messages received fromthe network. The routing network 110 records the registrations in theregistry 125. The client's registrations preferably remain in effect aslong as the client is displaying the associated page 118, although otherembodiments of the system 100 may use different criteria for determiningwhen to terminate the client's registrations.

FIG. 2 is an interaction diagram illustrating interactions among theserver 112, information provider 108/dynamic content provider 116(generically referred to as an “input source 210”), client 114, and therouting network 110 to update a property of a live object. Initially,the client 114 sends 212 a web page request to the server 112. Inresponse, the server 112 provides 214 to the client 114 the web pagecontaining or otherwise identifying the one or more live objects.Instructions encoded in the web page preferably cause the client 114 totransparently request 216 the activation module 124 from the routingnetwork 110. In response, the routing network 110 sends 218 theactivation module 124. The client 114 executes 220 the activation module124, which identifies the object IDs of the live objects at the clientand registers 222 the object IDs with the routing network 110. Therouting network 110 updates 223 its registry to identify the object IDsfor which the client 114 has registered.

At some point, the input source 210 sends 224 an update message to therouting network 110 in order to change a property of a live object atthe client 114. In one embodiment, the message from the input source 210to the routing network 110 contains only a single object ID and anupdate to a property of the identified object. In another embodiment,the message contains multiple object IDs and the corresponding propertyupdates. In this latter embodiment, the message may have an associated“Batch ID” that identifies the message as having multiple object IDs andupdates. Preferably, the information provider 108 can include a batch IDin a page 118 in the same manner as including an object ID. Likewise,the client 114 can preferably register for a batch ID with the routingnetwork 110 in the same manner as an object ID. In fact, the batch IDcan be the same as the object ID so that the client 114 registers forboth batch and non-batch messages by registering one ID. Alternatively,separate procedures can be established for registering batch messages.The client 114 preferably processes the component messages of a batch asif each message were delivered separately.

The routing network 110, in turn, routes 226 the message to each client114 that has registered for the specified object ID, preferably byutilizing standard Internet communications protocols, such as IPaddresses, etc. The activation module 124 at the client 114 processesthe message and updates 228 the property of the identified live object.If live objects having the same object ID appear in multiple locationsat the client 114 (e.g., at multiple locations on a web page beingdisplayed at the client), the activation module 124 preferably updateseach of the live objects having the specified ID. As a result, therouting network 110 allows live objects at the client 114 to bedynamically updated. Preferably, this routing and updating happensquickly enough to be considered “real-time” for the purposes of theinput source 210.

This update process, indicated within the dashed box 230 in FIG. 2, canrepeat an indefinite number of times and is fully asynchronous as to theinformation provider 210 and client 114. For example, the input source210 may send regular update messages to the routing network 110 as thescore of a sporting event changes or a stock price fluctuates, but maystop sending update messages once the sporting event ends or stockmarket closes. When the client 114 ends the display of a web pagecontaining the live object, or otherwise no longer desires to receiveupdate messages, the client preferably closes 232 the connection withthe routing network 110. The routing, network 110, in turn, updates 234the registry 125 to remove the client's object registrations. In anotherembodiment, the client 114 sends messages to the routing network 110that selectively register and/or de-register the client from one or moreobjects yet leaves the connection open in order to receive updatemessages pertaining to other objects.

FIG. 3 is a high-level diagram graphically indicating the many-to-manymapping performed by the routing network 110. Multiple input sources(labeled 210A-C) send update messages to the routing network 110. Eachupdate message preferably specifies at least one object ID and an updateto a property of the identified object. The routing network 110, inturn, selectively routes the update messages to the clients 114 thathave registered for the given object ID from the given input source 210.In FIG. 3, assume for example that clients 312A and 312B have registeredfor a given object ID while the other clients have not registered forthe object ID. Accordingly, the routing network 110 routes the updatemessage to clients 312A and 31213, but does not route the message toclients 312C-312H.

FIG. 4 illustrates an example of the capabilities of the dynamic contentrouting network 110. FIG. 4 illustrates two different web pages 410, 412containing sports scores. Although the web pages are formatteddifferently, each page contains the same scores for two professionalfootball games and two professional baseball games. Web page 410contains all four games under the heading “Local Sports Scores” whileweb page 412 contains the baseball games under the heading “BaseballScores” and the football games under the heading “Football Scores.”

There are various ways to internally represent the games and scores inthe web pages using live objects. In one embodiment, a “game” object isdefined having properties for the two teams involved in the game and thescore associated with each team. The game object is placed at a selectedposition in the web page and the properties of the object cause theinformation about the game to be displayed on the page. In anotherembodiment, “team” and “score” objects are defined, with the team objecthaving a property defining the name of a team and the score objecthaving a property defining a score. In this second embodiment, the teamand score objects are placed at selected locations on the page so thatthe proper teams and scores are aligned when the page is rendered. Inyet another embodiment, an object is defined having properties for thename of one team and a score associated with that team. Then, pairs ofthe objects are placed in the page in the proper alignment to indicatethe games and scores. In another embodiment, an object is defined havingproperties specifying names of two teams and a separate object isdefined having properties specifying two scores. In this lastembodiment, the two objects are placed in the page so that the names ofthe teams align with the associated scores. Obviously, additionalvariations of these representations are possible.

Assume for the example of FIG. 4 that the names of teams in a game arespecified by a “names” object having properties for the two team namesand the scores in the game are specified by a “scores” object havingproperties for two scores. In web page 410, a names object 414 havingproperties set to identify the “SF 49ers” and the “STL Rams” is locateddirectly under the “Local Sports Scores” heading. A scores object 416having a property set to identify the score of the game as “42” to “7”is directly to the right of the names object 414. In web page 412, theproperties of the second names object 418 identify the same game usingslightly different terminology: “SF” and “STL.” However, this namesobject 418 is aligned with the same scores object 416 as is utilized inweb page 410.

Thus, the same scores object 416 is utilized in different positions ineach web page 410, 412. In order to update the score of the SanFrancisco 49ers vs. St. Louis Rams football game on both web pages, theinput source 210 simply sends an update message to the routing network110 specifying the object ID for the scores object 416 and the update tothe score property. The routing network 110 routes the update message tothe appropriate clients 114, and the clients update the appropriatescore regardless of the particular page layout.

The input source 210, i.e., the information provider 108 and/or dynamiccontent provider 116 can use a variety of tools to generate the updatemessages. FIG. 5 is a block diagram illustrating an input source 210 andthe tools available to it for, generating the update messages. Othertools can be utilized in addition to or instead of the ones describedherein.

Preferably, the tools allow the input source 210 to access anapplication programming interface (API) provided by the routing network110 for accepting messages. In one embodiment, the messages sent by theinput source 210 are in the same format as utilized by the activationmodule 124 at the client 114. In an alternative embodiment, the messagesprovided to the routing network 110 are in a different format and therouting network translates the messages into the format utilized by theactivation module 124.

In one embodiment, the input source 210 utilizes a data pump module 510to access the API. The data pump module 510 reads an extensible markuplanguage (XML) file containing one or more object IDs and the new valuesfor the identified objects at regular intervals and automaticallygenerates API calls that send messages representing changes to objectproperties to the routing network 110. In another embodiment, the datapump module 510 is event-driven and reads the XML file in response to achange in the file or some other occurrence.

In another embodiment, the input source 210 utilizes a director consolemodule 512 to access the API. Preferably, the director console module512 presents an administrator with a graphical interface displaying thecontents of the page 118. For example, the administrator may use thedirector console 512 to edit textual data, images, and/or any objects orproperties of objects on the web page. After editing, the administratoruses a “send update” button or similar technique to cause the directorconsole module 512 to send messages for the changed objects andproperties to the routing network 110 via the API.

In another embodiment, the information provider 108 and dynamic contentprovider 116 work together as the input source 210 by using a contentmanagement system module 514 to access the API. Preferably, the contentmanagement system module 514 resides at the information provider 108 andreceives object property updates from the dynamic content provider 116.The content management system module 514 preferably updates theproperties of the live objects in the page 118 stored at the server 112and also sends messages for the changed properties to the routingnetwork 110. In this manner, the page 118 at the server 112 and the webpage displayed at the client 114 are updated almost simultaneously. Inone embodiment, the dynamic content provider 116 sends the updatemessages to the routing network 110 instead of to the informationprovider 108. Embodiments of the system 100 can also utilize anycombination of the content management techniques described herein.

For example, the tools described above can generate a message having thefollowing code for updating the text displayed by a score object to “2”:

LiveObject score=new LiveObject(“Bang$homeScoreID”);score.setProperty(“innerText”, “2”).

This code sets the innerText property of the object having object ID“Bang$homeScoreID” to “2.” The tools use the API to pass this message tothe routing network 110.

Turning now to the actions performed at the client 114, FIG. 6 is a flowchart illustrating the steps performed by an embodiment of theactivation module 124. Those of skill in the art will recognize thatdifferent embodiments may perform the steps of FIG. 6 in differentorders. The activation module 124 generally performs three functions:register object IDs with the routing network 110, handle messagesreceived by the client 114 from the network in order to update theproperties of live objects, and control communications between theclient and the network.

In order to register object IDs, the activation module 124 preferablyparses 610 the page 118 received from the server 112 and identifies theobject IDs of the live objects. In an alternative embodiment, theactivation module 124 identifies only a subset of the object IDs, suchas the IDs of only live objects that are currently being displayed bythe web browser 120. Alternatively, a list of object IDs may bepre-encoded in the web page in addition to the objects themselves,thereby enabling easy identification by the activation module 124. Inyet another embodiment, a user of the client 114 selects the object IDsto register.

The activation module 124 preferably opens 612 a connection between theclient 114 and the routing network 110. The activation module 124 canopen 612 this connection before or after the activation module receivesand/or parses the page 118. In some cases, the client 114 is locatedbehind a firewall that puts a restriction on the types of connectionrequests the client can make. A firewall might, for example, block allnon-HTTP traffic. For this reason, the activation module 124 preferablywraps the connection request in an HTTP header in order to get therequest to the routing network 110 through the firewall.

The activation module 124 uses the connection between the client 114 androuting network 110 to register 614 the object IDs by communicating tothe routing network 116 a vector (e.g., a list or array) containing theidentified object IDs. In order to accomplish this task through thefirewall, the activation module 124 preferably puts the vector into astring, referred to as “object data,” and then preferably creates anHTTP message to communicate the object data to the routing network 110.A schematic example is as follows:

POST / HTTP/1.1\r\n Content-Length: <length of object data> \r\n \r\n<object data>where <object data> is the object ID list. When the routing network 110receives such an HTTP request, it extracts the object data and updatesthe registry 125 to indicate that the client 114 has registered for theidentified objects.

If the web browser 120 loads 616 a new page, or otherwise terminatesdisplay of the objects on the initial page, the activation module 124associated with the initial web page preferably terminates 618 theclient's connection with the routing network 110. Those of skill in theart will recognize that this termination 618 can occur asynchronouslywith the other steps illustrated in FIG. 6. Thus, the location of steps616 and 618 represents only one possible place in the sequence of stepswhere the termination may occur.

If the connection is not terminated, the activation module 124preferably waits until it receives 618 a message from the routingnetwork 110 specifying an object ID and an update to a property of theidentified object. In one embodiment, this message is received as HTTPdata. Upon receipt of the message, the activation module 124 preferablyextracts 620 the object ID and update from the HTTP data. Then, theactivation module 124 updates 622 the property of the identified object,or causes the object to be updated, as specified by the message.

The sequence of receiving messages 618, extracting data 620, andupdating objects 622 is preferably repeated until a new page is loaded616 or the connection with the routing network 110 is otherwiseterminated. Although not shown in FIG. 6, in certain circumstances, suchas when a user action with respect to the page 118 activates a new liveobject, the activation module 124 may register new object IDs with therouting network 110 without first downloading and parsing a new page. Inone embodiment, if the newly-loaded page contains live objects, then theprocess of downloading the activation module 124 and updating theobjects as described by FIG. 6 is repeated. In an alternativeembodiment, the activation module 124 remains active at the client 114and, therefore, the client does not re-download the activation modulefrom the routing network 110. Instead, the already-present activationmodule 124 performs the live-enabling process on the new page.

FIG. 7 is a block diagram illustrating a lower-level view of the routingnetwork 110 according to an embodiment of the present invention. Thoseof skill in the art will recognize that there are many alternative waysto implement the functionality of the routing network 110. FIG. 7illustrates multiple input sources (labeled 710A-D) representative ofsources providing messages to the routing network 110, such as aninformation provider 710A and a dynamic content provider 710B. FIG. 7also illustrates multiple clients (labeled 712A-F) representative of themany clients in communication with the routing network 110 at any giveninstant.

Internally, the routing network 110 is preferably divided into one, ormore clusters 714. In FIG. 7, the, routing network 110 has threeclusters 714A, 714B, 714C, although the number of clusters can varydepending upon the processing needs of the network. An input-side globalload balancer 716 preferably routes messages from the input sources 710to the clusters 714. Similarly, a client-side global load balancer 718preferably routes connection requests from the clients 712 to theclusters 714. The load balancers 716, 718 are designed to ensure thatload is distributed among the clusters 714 according to a predeterminedheuristic. For example, the load may be distributed evenly among theclusters 714 or a more powerful cluster may be distributed a majority ofthe load. In one embodiment, one load balancer performs the functions ofthe input-side 716 and client-side 718 load balancers and utilizesconventional Domain Name System-(DNS-) based load balancing.

Each cluster 714, of which cluster 714A is representative, preferablycontains an input-side cluster load balancer 720A and a client-sidecluster load balancer 722A. The cluster load balancers 720A, 722Afunction similarly to the corresponding global load balancers 716, 718in that the input-side cluster load balancer 720A balances and routesincoming messages among one or more gateways 724A and the client-sidecluster load balancer 722A balances and routes incoming connectionrequests among one or more nodes 726A and application servers 728A.

In one embodiment, the functionality of the two client-side cluster loadbalancers 720A, 722A is provided by one component. This single-componentload balancer initially determines whether an incoming request is froman input source 710 seeking to send a message to a gateway 724A, aclient 712 seeking a connection to a node 726A, or a client seeking aconnection to an application server 728A. Then, the load balancer routesthe messages/connection requests among the gateways 724A, nodes 726A,and application servers 728A within the cluster 714. In one embodiment,the single-component load balancer provides layer seven load balancing(i.e., load balancing at the application layer). Preferably, the loadbalancing for the nodes 726A and application servers 728A are performedby the same component since, for security reasons, most client webbrowsers only permit an application (e.g., the activation module 124) totransparently connect to the location from which the application wasdownloaded.

Alternative embodiments of the routing network 110 may combine theglobal 716, 718 and cluster 720A, 722A load balancers and/or incorporatethe functionality of the load balancers into different components withinor outside of the clusters 714. In addition, alternative embodiments mayomit one or more of these load balancers. For example, having differentclusters 714 serve different customers might obviate the need for theglobal load balancers 716, 718.

The gateways 724A in the cluster 714 receive the messages from the inputsources 710 and direct the messages to the appropriate node or nodes726A. In one embodiment, each gateway 724A maintains a persistent TCPconnection to every node 726 in every cluster 714 and directs everymessage to every node. Therefore, although a gateway 724A is locatedinside a cluster 714A and receives connections via the cluster'sinput-side load balancer 720A, the gateway's scope spans the entirerouting network 110. This broad scope allows messages from any inputsource to reach any client 712.

In an alternative embodiment of the routing network 110, each gateway724 maintains a persistent TCP connection to all nodes 426 in the samecluster 714 and at least one connection to at least one gateway in eachof the other clusters. This embodiment reduces the number ofsimultaneous TCP connections maintained by each gateway 724. In anotheralternative embodiment, each cluster 714 also includes a gatekeeper (notshown in FIG. 7) that maintains connections with the gateways 724 ofother clusters. A gateway 724 forwards messages to the gatekeeper, whichthen distributes the messages to the gateways of other clusters 714.

Since a gateway 724 does not control the rate at which it receivesmessages from input sources 710, it is possible for the gateway toreceive messages faster than it can process them (i.e., send themessages to the nodes). Therefore, each gateway 724 preferably maintainsa queue 730 of messages that have been received but not yet processedorder to avoid losing messages. In one embodiment, the gateway 724 dropsmessages if the queue 730 becomes too long. In another embodiment, thegateway 724 utilizes priorities assigned to certain messages or inputsources to determine which messages to drop.

The nodes 726 preferably transmit messages received from the gateways724 to the clients 712 that have registered in the object IDs identifiedby the messages. If no clients 712 have registered the object IDspecified by a message, the node preferably ignores the message. A node726 preferably maintains an instance of the registry 125 as a hash table732 containing the object IDs registered by clients 712 connected to thenode. In one embodiment, the hash table 732 associates each object IDwith a linked list containing one entry for each client 712 that hasregistered for that object ID. Each entry in the linked list preferablycontains a pointer to a socket representing the connection to thecorresponding client 712. As is known in the art, the pointer to thesocket, typically called a “file descriptor,” represents an address towhich the node can write in order to send the message to thecorresponding client. Preferably, the node 726 adds to the hash table732 and/or linked list every time a client 712 registers an interest inan object and deletes the corresponding entry from the hash table and/orlinked list when the client disconnects from the node or otherwiseindicates that it is no longer interested in a particular object.

Alternative embodiments of the present invention utilize other datastructures in addition to, or instead of, the hash table 732 and linkedlist, and/or may utilize different data within the data structures. Forexample, one embodiment of the routing network 110 has a hierarchy ofnodes within each cluster 714. Different nodes in the hierarchy mayhandle messages received from certain input sources 210, or processmessages sent to different clients 712. In this embodiment, the linkedlists may point to nodes lower in the hierarchy, instead of to socketsleading to the clients 712. Another embodiment lacks the node hierarchy,yet assigns certain nodes to certain input sources 210 or clients 712.

The application server 728 within each node 714 preferably serves theactivation module 124 to the clients 712 in response to client requests.In addition, the application server 728 serves any other modules thatmay be required or desired to support the environment 100. In analternative embodiment of the routing network, a single applicationserver 728 fulfills all of the client requests. This application server728 may be within a certain cluster 714 or independent of the clusters.However, this single-application-server embodiment is less desirablebecause it lacks redundancy.

Preferably, the routing network 110 utilizes conventionalsingle-processor computer systems executing the Linux operating system(OS). Preferably, each component of the routing network 110 isimplemented by a separate, dedicated computer system in order to enablethe separate optimization of the components. The input/output (I/O)functionality of the OS is preferably enhanced through the use of anon-blocking OS package such as NBIO available from the University ofCalifornia, Berkeley, Calif. Based on the assumption that connectionswith the nodes 728 are long-lived, the OS is preferably configured tonot allocate resources toward monitoring idle connections. Instead, thewell-known/dev/poll patch is preferably applied to the OS in order toprovide advanced socket polling capabilities.

Moreover, the TCP/IP stack in the OS is preferably optimized in order toquickly output messages. In one embodiment, the retransmit timer in thestack is reduced from 200 ms to 50 ms. This timer determines how longthe stack waits for an acknowledgement (ack) that a sent packet wasreceived. Due to the way the Linux kernel implements the retransmittimer, the kernel will not send pending outbound packets (even if theack has been received) until the initial retransmit timer has expired.Reducing the retransmit value minimizes the effect of this delay. If anack is not received before the retransmit timer expires, an embodimentof the present invention increases the retransmit value for the affectedTCP connection and the unacknowledged packet is retransmitted. Inaddition, the TCP/1P stack preferably utilizes Nagle's algorithmfunctionality to concatenate a number of small messages into a largermessage, thereby reducing the number of packets sent by the routingnetwork 110.

FIG. 8 is a flow chart illustrating steps performed by a node 726 in acluster 714 to perform object-based routing of a message received froman input source via the gateway 724. Initially, the node 726 receives810 the message from an input source 710. The node 726 extracts 812 theobject ID from the message. In addition, the node 726 optionallytransforms 814 the message to convert it from the format utilized by theinput source 710 into the format utilized by the activation module 124at the client 712. As described above, in one embodiment the messageformat utilized by the input source 710 is identical to the messageformat utilized by activation module 124. In this embodiment, therefore,the node 726 does not need to transform the message. In an alternativeembodiment wherein the input source 710 and activation module 124utilize different message formats, the node 726 preferably transformsthe message. The node 726 looks up 816 the hash table entrycorresponding to the extracted object and information provider IDs todetermine the linked list of clients 712 that have registered in theobject referenced by the message. Finally, the node 726 transmits 818the message to each of the registered clients 712. In an alternativeembodiment, the node 726 optionally transforms the message after, asopposed to before, looking up the registered clients in the hash table.Transforming the message at this latter stage enables the node 726 totransform the message according to the specific requirements of theregistered clients 712.

Delivering Personalized Content Using the Dynamic Content RoutingNetwork

FIG. 9 depicts an example of a page 118 according to one embodiment. Inone embodiment, page 118 may be a web page. In other embodiments, page118 may be any page generated by a software application, such as a wordprocessing document, a spreadsheet, an email, etc. As shown, page 118includes a plurality of sections 902, such as a market data section902-1, a news headline section 902-2, a recent trades section 902-3, andan account balances section 902-4. Although these sections are shown, itwill be understood that any number of sections may be provided in page118.

In one embodiment, page 118 may be provided by a web-based application.Routing network 110 may be used to deliver purchase prices for stocksand bonds to a large number of clients 114. Each client's page 118 mayinclude the same sections 902, but information for a certain section 902may be personalized (e.g., different) for each user. For example, marketdata section 902-1 may be the same for all the users. However, recenttrades section 902-3 and account balances section 902-4 may bepersonalized for each user. For example, the recent trades made by aspecific user and their account balances may be personal to a user, andmay only be sent to the specific user. Accordingly, personalizedinformation may be any information specific to a user. It should beunderstood that different users may have personalized information thatmay be substantially the same; however, the personalized information foreach user would be specific to each user.

In one embodiment, when a trade closes for a given user, only his/herpage 118 should be updated (e.g., under the recent trades section902-3). Accordingly, personalized information should only be sent tothis user.

In one embodiment, different content for section 102 may be delivered bydifferent input sources 210. For example, an input source 210 mayprovide content for news headline section 902-2 and another input source210 for market data section 902-1. In addition, real-time data may beprovided by multiple input sources 210. Input source 210 may be locatedremotely from routing network 110 and client 114, or may be, in otherembodiments, part of routing network.

The real-time information sent to page 118 may be delivered usingrouting network 110. In one embodiment, each stock 904 may be assignedan ID, and messages published to that ID may be delivered to every user.A live object may be then be updated. A live object may be any data thatcan be updated. For example, a live object may be any data included in adata representation for page 118, such as software code for displayingan element of page 118, an element being displayed on page 118, etc. Inaddition to the generic information, personalized information may bedelivered to recent trades section 902-3 and account balances section902-4. Further, a combination of generic and personal information may bedelivered for a section. For example, generic and personal informationmay be delivered to news headline section 902-2.

In one embodiment, in order to deliver personalized messages to users, abatching capability of routing network 110 may be used. In thisembodiment, each user may be assigned a personalized ID. Thepersonalized ID may be unique or specific to the user. As will bediscussed below, the personalized ID may also be specific to a group ofusers and not just one user. The personalized ID can be put anywhere ina data representation for their page 118 (such as in the body tag ofsoftware code for page 118). Live objects in the data representation maythen be associated with generic IDs. The live objects may be found in apage 118 and personalized information may be displayed for the liveobjects. The generic IDs may be the same for a plurality of users. Forexample, recent trades section 902-3 of a web-based trading applicationmay be marked with the ID “recentTradesID”. This ID may be the same forevery user's page 118, even though personalized information may bedisplayed there for each user.

In one embodiment, input source 210 provides a batch message using thefollowing format [personalizedID, (genericID #1, “personalizedinformation #1”), (genericID #2, “personalized information #2”)].PersonalizedID may be an ID personalized to a user. GenericID #1 andgenericID #2 may be an IDs generic across many users. Personalizedinformation #1 and #2 may be any information that can be used to updatea page. In one example, a message for account balances may be sent inthe above batch message using the following message, [personalizedID,(accountbalancesID, “balance information”), . . . ]. This message may beused to update the account balance of a use's account with personalizedinformation for the user.

Routing network 110 delivers the batch message to a user registered forthe personalized ID. When the batch message arrives at a client 114associated with the user, it may be treated as if the messages(genericID #1, “personalized information #1”) and (genericID #2,“personalized information #2”) were sent to client 114. The personalizedID may not be used after the message is received.

In one embodiment, the browser of client 114 evaluates a datarepresentation for page 118 and finds the IDs of genericID #1 andgenericID #2. Live objects on page 118 may be updated with personalizedinformation #1 and #2. An information provider does not need to know orunderstand the structure of the user's page 118. Also, because updatemessages may not include any DOM information, the message itself issimple. For example, if one of the messages may be (accountbalancesID,“balance information”), the browser of the client may update accountbalances section 902-4 with the information as specified by the updatemessage (i.e., the “balance information” of the update message).

Thus, personalized information for multiple users may be sent to ageneric ID that may be used to update live objects included on pages 118for multiple users. The personalized ID may be used to send personalizedinformation to a user using the above-referenced batch messagetechniques. Because the live objects may have identical IDs, an inputsource 210 can deliver multiple personalized messages to the samegeneric ID for a live object. This reduces the number of IDs that may beused.

FIG. 10 depicts a system 1000 for delivering personalized messages usingrouting network 110 according to one embodiment. System 1000 includes aplurality of clients 114, routing network 110, and an input source 210.

Input source 210 may be capable of sending personalized messages usingthe batching capability of routing network 110. As shown, three batchmessages, messages #1, #2, and #3, may be sent by input source 210.Messages #1, #2, and #3 may be sent to three different personalized IDs:personalized ID #1, personalized ID #2, and personalized ID #3. A batchmessage includes a message sent using the generic IDs of recentTradesIDand accountbalancesID. Personalized information, however, may beincluded in each message for the IDs of recentTradesID andaccountbalancesID for different users.

The three messages may be sent from input source 210 to routing network110. Routing network 110 determines which clients 114 have registeredfor the personalized IDs. As shown, a client 114-1 has registered forpersonalized ID #1, client 114-2 has registered for personalized ID #2,and client 114-3 has registered for personalized ID #3. Accordingly,message #1 may be sent to client 114-1 because that client 114-1 (or auser) has registered for personalized ID #1. Further, message #2 andmessage #3 have been sent to client 114-2 and client 114-3 because thoseclients 114-2 and 114-3 have registered for the correspondingpersonalized IDs #2 and #3, respectively. Clients 114-1, 114-2, and114-3 can then update their pages 118 with the information provided forthe IDs of recentTradesID and accountBalanceID. As shown, client 114-1has displayed personalized trade information #1 and personalized balanceinformation #1, client 114-2 has displayed personalized tradeinformation #2 and personalized balance information #2, and client 114-2has displayed personalized trade information #3 and personalized balanceinformation #3.

Accordingly, three messages may be sent with information for the genericID recentTradesID. However, using a batched message, the message may besent to three different clients 114. Thus, client 114 may receivepersonalized information for the generic ID.

FIG. 11 depicts a simplified flowchart 1100 for generating a batchmessage according to one embodiment. In step 1102, an input source 210determines personalized information for a user.

In step 1104, a personalized ID and generic ID for the personalizedinformation may be determined. In one embodiment, input source 210 doesnot need to know where or how to send the personalized information to auser. Rather, input source 210 may associate the personalizedinformation with a generic ID and generate a batch message that may besent to the personalized ID.

In step 1106, a batch message may be sent with the personalized ID torouting network 110. The format of the batch message may be sent asdescribed above or through any other formats. Accordingly, input source210 may send a batch message to the personalized ID. How or where toroute the message to a user may not need to be determined by inputsource 210. Rather, routing network 110 may route the batch message asdescribed below.

FIG. 12 depicts a simplified flowchart 1200 of a method for routing abatch message to a client 114 according to one embodiment. In step 1202,the batch message may be received from input source 210. In step 1204, aclient 114 may be determined that may be registered for the personalizedID found in the batch message. In one embodiment, a client 114 maydownload an activation module 124 and register IDs with routing network110. This process is described in more detail above. When a batchmessage is received from input source 210 for the personalized ID,routing network 110 may route the batch message to client 114 using thepersonalized ID in step 1206.

FIG. 13 depicts simplified flowchart 1300 for a method for processing abatch message at a client 114 according to one embodiment. In step 1302,a batch message may be received from routing network 110. The batchmessage may be directed to a personalized ID and routed according topreferences associated with the personalized ID. For example, thepersonalized ID may be associated with an IP address and the message maybe received at a client 114 corresponding to that IP address.

In step 1304, a generic ID in the batch message may be determined. Thisgeneric ID may be the same ID that may be found on multiple users' pages118.

In step 1306, personalized information for the generic ID may bedetermined. For example, the personalized information may bepersonalized information and may be specific to the client 114.

In step 1308, a live object may be updated with the personalizedinformation using the generic ID. For example, client 114 may determinea live object on page 118 that may be associated with the generic ID. Aproperty of a live object may be updated with the personalizedinformation.

For example, referring to FIG. 9, a live object may be found in recenttrades section 902-3 of page 118. A recentTradesID may be included in adata representation for page 118. Client 114 thus displays thepersonalized information corresponding to a position as referenced bythe ID of recentTradesID in the data representation for page 118.Accordingly, routing network 110 or the input source 210 may not need tounderstand the structure or DOM of a user's page 118. Client 114 may beable to update recent trade section 902-3 as specified by thepersonalized information for recentTradesID.

The same generic ID may also be used in cases where some messages may beintended for a wide audience (e.g., not personal) and others may bepersonalized, such as in news headline section 902-2 of page 118. Forexample, input source 210 may send standard headlines to users, using ageneric ID, such as the following message, <NewsheadlineID>, <“Newsheadline information”>, and send personalized messages using a batchmessage, such as [<personalizedID>, (<NewsheadlineID>, <“Personalizednews headline information”>)]. The first message may send news headlineinformation to any users that subscribe to the ID of NewsheadlineID andthe second message may send personalized news headline information tothe user associated with personalizedID. Accordingly, the same genericID may be used to send standard headlines that may be sent to all users.The generic ID may also be used as a personalized ID by sending a batchmessage to the personalized ID for a user. Personalized headlines may besent to a user associated with the personalized ID. An informationprovider 210 may switch back and forth between standard headlines andpersonalized headlines for generic IDs.

The batch message may also be used to send semi-personalized messages,i.e., messages to groups rather than individuals. Just as an individualuser may have a live object associated with the personalized IDsomewhere on his/her page 118, members of a group can have a live objectfor a group personalized ID located on their pages 118. To send a groupof users a message within the news headline section 902-2 of their pages118, information provider 214 may use a batch message sent to a grouppersonalized ID, such as [<groupPersonalizedID>, (<newsheadlineID>,<“personalized group headline information”>)]. All (and only) members ofthe group may receive this message because they may be associated withthe group personalized D. This technique may not require that members ofthe group are viewing identical pages. Rather, members of the group maydisplay the information for newsheadlineID in whichever way they desire.

Accordingly, a batch message may be used to send personalizedinformation that may be associated with generic IDs; however, the batchmessage may be sent to a personalized ID specific to a user.Accordingly, the number of IDs used by a content provider 214 may beminimized. However, the power of sending personalized messages may stillbe maintained using the personalized IDs.

In one embodiment, the term “and/or” may indicate that any combinationof elements connected by “and/or” may be used. For example, two words orexpressions in a phrase using “and/or” may mean one or the other orboth. In one embodiment, the term “substantially” may mean being largelybut not wholly that which may be specified, or all that may bespecified. In one embodiment, the term capable of may mean configured,adapted, able, etc. For example, the term capable of performing anaction may mean an element may be able to perform the action, may beconfigured to perform the action and/or may be adapted to perform theaction.

Embodiments of the disclosure can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium as a plurality ofinstructions adapted to direct an information processing device toperform a set of steps disclosed in one embodiment. Based on thedisclosure and teachings provided herein, a person of ordinary skill inthe art will appreciate other ways and/or methods to implement thedisclosure.

The above description is illustrative but not restrictive. Manyvariations of the disclosure will become apparent to those skilled inthe art upon review of the disclosure. The scope of the disclosureshould, therefore, be determined not with reference to the abovedescription, but instead should be determined with reference to thepending claims along with their full scope or equivalents.

1.-30. (canceled)
 31. A method, comprising: determining, by a computingdevice, customized update information for a client device registered toreceive the customized update information based on loading of a webpageby the client device; determining, by the computing device, a customizedidentifier and a generic identifier associated with the customizedupdate information; generating, by the computing device, an updatemessage including the customized identifier, the generic identifier, andthe customized update information; and transmitting the update messageto the client device to cause an update to a property of an objectassociated with the generic identifier.
 32. The method of claim 31,wherein the customized identifier is associated with the client deviceand the generic identifier is generic to a plurality of client devices.33. The method of claim 31, wherein the transmitting the update messagecomprises delivering the update message using a batch process.
 34. Themethod of claim 31, wherein the object is included in a datarepresentation at the client device.
 35. The method of claim 34, whereinthe data representation is a web page or an application program.
 36. Themethod of claim 31, wherein the object includes the customizedidentifier and the generic identifier.
 37. A system, comprising: asource node configured to: determine customized update information for aclient device registered to receive the customized update informationbased on loading of a webpage by the client device; determine acustomized identifier and a generic identifier associated with thecustomized update information; generate an update message including thecustomized identifier, the generic identifier, and the customized updateinformation; and transmit the update message to the client device tocause an update to a property of an object associated with the genericidentifier.
 38. The system of claim 37, wherein the customizedidentifier is associated with the client device and the genericidentifier is generic to a plurality of client devices.
 39. The systemof claim 37, wherein the transmitting the update message comprisesdelivering the update message using a batch process.
 40. The system ofclaim 37, wherein the object is included in a data representation at theclient device.
 41. The system of claim 40, wherein the datarepresentation is a web page or an application program.
 42. The systemof claim 37, wherein the object includes the customized identifier andthe generic identifier.
 43. A computer-readable medium storinginstructions, the instructions comprising: instructions to determinecustomized update information for a client device registered to receivethe customized update information based on loading of a webpage by theclient device; instructions to determine a customized identifier and ageneric identifier associated with the customized update information;instructions to generate an update message including the customizedidentifier, the generic identifier, and the customized updateinformation; and instructions to transmit the update message to theclient device to cause an update to a property of an object associatedwith the generic identifier.
 44. The computer-readable medium of claim43, wherein the customized identifier is associated with the clientdevice and the generic identifier is generic to a plurality of clientdevices.
 45. The computer-readable medium of claim 43, wherein theinstructions to transmit the update message comprises instructions todeliver the update message using a batch process.
 46. Thecomputer-readable medium of claim 43, wherein the object is included ina data representation at the client device.
 47. The computer-readablemedium of claim 46, wherein the data representation is a web page or anapplication program.
 48. The computer-readable medium of claim 43,wherein the object includes the customized identifier and the genericidentifier.
 49. A system, comprising: a network node configured to:receive an update message including a customized identifier, a genericidentifier, and customized update information, the customized updateinformation being based on loading of a webpage by a client device;identify the client device associated with the customized identifier;and route the update message to the client device to cause an update toa property of an object associated with the generic identifier.
 50. Amethod, comprising: receiving, using a computing network, an updatemessage including a customized identifier, a generic identifier, andcustomized update information, the customized update information beingbased on loading of a webpage by a client device; identifying, using thecomputing network, the client device associated with the customizedidentifier; and routing, using the computing network, the update messageto the client device to cause an update to a property of an objectassociated with the generic identifier.